Skip to main content

LibreSpace Meeting on October 3rd, 2025

Two of their own missions (Phasma, HELEO) that used libcsp with satnogs comms

https://gitlab.com/librespacefoundation/phasma/phasma-obc-software

https://gitlab.com/librespacefoundation/heleo/heleo-satnogs-comms-mcu-sw

A Transcription or full call recording of the first 30min and extensive notes of the rest of the conversation can be requested from me (Pascal).

Useful products​

  • Segger J-Link (or a smaller one)
  • UART-to-USB dongle
  • candlelight CAN-to-USB adapter

Words and abbreviations​

SC: Satnogs COMMS

openocd: Open-Source On Chip Debugger used for debugging

can, canA, canB, CAN: CAN Bus hardware interface, will be the communication protocol on SAGE. SC has 2 of them thus A and B

csp, libcsp: LibCSP software that makes CAN communication much easier, used on SAGE

PC104: 56-Pin Array where all electric signals will be routed on SAGE (standard for cubesats)

Cortex-Debug: VSCode extension, extremely useful for anything embedded

Segger J-Link: Different brand of device to connect to the SC, we have an STLink-V2 right now (Manolis strongly recommends getting a J-Link)

Phasma, HELEO: Missions by LibreSpace, where they have demonstrated that it works

Debugging​

Debug overlay​

To debug the software, build it using the debug overlay! To do this, add the following to the build command:

-- -DEXTRA_CONF_FILE=../satnogs-comms-software-mcu/boards/lsf/satnogs_comms/debug.conf. So from inside the directory sage-com-satnogs-sw-workspace/sage-com-satnogs-sw, run the command west build -p -b satnogs_comms@0.3.1 app -- -DEXTRA_CONF_FILE=../satnogs-comms-software-mcu/boards/lsf/satnogs_comms/debug.conf to build the debug version of the software.

If it does not work, consult the Overlay Files/Path section

Starting a Debugging Session​

Do not actually use west debugserver. Instead, just use the run and debug button in VSCode.

.vscode Files​

He will send me his launch config (if they are on the Phasma gitlab, use these). Adapt them for your OS and openOCD carefully. Especially launchFiles: and another (should be obvious) launch.json property to make them usable with the STLink. If STLink instead of openocd is used, SWO output will not work, even if the hardware is STLink. If SWO does not work with openocd on the STLink, let Manolis know.

One notable thing is the "Cortex-Debug.ToolchainPrefix": "arm-zephyr-eabi", which has to be placed in settings.json to stop the error of “cannot find arm-none-eabi…”.

Logging​

A logger example can be found in Phasma obc/subsystems/satellite.cpp and logger.hpp. RTT uses SWO and is more performant than UART, RINGBUF or STORAGE. Segger RTT will handle logs, but RTT is a bit more difficult than UART. UART takes a bit longer at runtime, even if it uses DMA. If no interface is specified, any logging (log.log(…)) will use all of them but performance will drop accordingly.

Connecting to the Cortex-Debug Serial monitor has not been attempted.

UART dongle, connected to relevant overlay file PC104 pins (see Overlay Files) works. SWO (RTT) should be visible with STLink. SWO will be visible in a new terminal window (named swoconsole or gdb-server or similar). Note: gdb-server might not be the same as SWO console, I do not know right now.

The latest firmware should be able to do SWO over STLink to see live information while in debug mode. This does not work in release build mode!

The SWO console (or gdb-server) window will start logging by showing HW and SW information and all further logs will appear there. This needs to be tested.

Libcsp and CAN​

CAN bus setup​

By default, SC uses canA with encapsulation to make communication frames larger. For this, SC uses isotp. SC can also use canB and disable canA. in one example, the satellite uses canA and SC drops isotp encapsulation and canB can be specified.

Any can bus run by SC should use isotp. Yamcs is really powerful, but does not work directly with libcsp. Use one can for each.

To interact between libcsp and SC, see Phasma Example.

Phasma Example​

The Phasma mission uses canB for isotp and canA for libcsp, so much like we would be doing (I do not know which can we use for libcsp). In the Phasma file prj.conf, canA has been disabled and canB is enabled. canA is then used over canA, visible in csp.cpp.

Interaction between libcsp and SC can be found on Phasma OBC software/subsystems/adcs.cpp, where RX is described around line 50 and TX around line 65. On Phasma, this interaction is complicated because of encapsulation. On HELEO is a simpler implementation.

Manolis wrote it on a fork but merged it into main. If it is not there, check his fork (don’t know the name). The mainfest west file will explain it somehow (unclear).

Recommendations for CAN communication​

Use SC with the default config, and use the second can to interact with SC over Yamcs. Study yamcs, it is really powerful for things like telemetry!

Get a “Candlelight” device, to directly read CAN with USB!

Overlay Files​

Path​

Use either the full path or the correct relative path when building the app, since with build app the paths are relative to the app directory, not sage-com-satnogs-sw. In our specific case, use one of the following options while inside the sage-com-satnogs-sw-workspace/sage-com-satnogs-sw folder (the overlay files are just an example):

  1. west build --board=satnogs_comms@0.3.1 -d build app --pristine -- -DEXTRA_DTC_OVERLAY_FILE="C:\PATH\TO\SAGE\WORKSPACE\sage-com-satnogs-sw-workspace\sage-com-satnogs-sw\satnogs-comms-software-mcu\boards\lsf\satnogs_comms\log_uart_pc104_p11_tx_p12_rx.overlay;C:\PATH\TO\SAGE\WORKSPACE\sage-com-satnogs-sw-workspace\sage-com-satnogs-sw\satnogs-comms-software-mcu\boards\lsf\satnogs_comms\gnss_uart_pc104_p13_tx_p15_rx.overlay"
  2. west build --board=satnogs_comms@0.3.1 -d build app --pristine -- -DEXTRA_DTC_OVERLAY_FILE="..\satnogs-comms-software-mcu\boards\lsf\satnogs_comms\log_uart_pc104_p11_tx_p12_rx.overlay;..\satnogs-comms-software-mcu\boards\lsf\satnogs_comms\gnss_uart_pc104_p13_tx_p15_rx.overlay"

General knowledge​

Bootloader​

SC flight config can support 2 firmwares and if one gets corrupted, the bootloader can automatically switch to the other one. However, debugging while using a bootloader becomes a nightmare, so this should be the last step. Additionally, SC (with bootloader) supports over-the-air update including a fallback, where the bootloader will automatically use the old version as fallback if the software upgrade does not work.

Before attempting this, consider a meeting with Manolis again to see how it all works (his advice).

Messaging channel to chat with all developers​

There is a matrix messaging channel, get the link on request by me (Pascal).